Organizations can run and customize existing database application programming interfaces (APIs) or build new custom database APIs based on particular business needs. Database triggers can be present within the APIs that are procedural codes that are executed in response to user interactions with a database. For example, a trigger can be a code that is executed before or after various types of database operations are executed such as: insert, update, delete, merge, undelete, etc. A trigger can be used to perform a number of automatic actions, such as cascading changes through related tables, enforcing column restrictions, comparing the results of data modifications, and maintaining the referential integrity of data across a database. The standard trigger procedure is to activate a trigger function in an API or provide a trigger code that is directed towards a specific entity.
Conventional “tight triggers” require that specific entities be defined and applied to the trigger at the time the database is created and before the trigger program is compiled. These tight triggers are inefficient for situations where the entity is not defined at the time the trigger is developed. Accordingly, it is desirable to provide “loose triggers” that are not tightly coupled to an entity.